我與 Angular 的相遇

相信講到前端框架，大家第一時間想到的通常會是 Vue、React，甚至也有人會推薦 Svelte 這類近年討論度很高的框架。但一講到 Angular，很多人的第一印象可能就像看到一座大城堡一樣：東西很多、規則很多，一時之間不知道該從哪裡開始。甚至當你真的去找相關討論時，也會發現 Angular 開發者相對沒有那麼容易遇到，這是我這幾年接觸下來，對 Angular 生態的一個感受。

但這並不代表 Angular 不好，也不代表它沒有人使用。我覺得比較大的原因，是 Angular 的入門門檻確實相對高一些。從一開始就會接觸 TypeScript，接著還要理解 Dependency Injection、RxJS、Change Detection 等概念，對當時剛接觸 Angular 的我來說，這些東西真的很讓我頭痛。

也因為相關文章相對比較少，我一直很想把這兩年自己研究 Angular 的過程好好記錄下來。雖然現在的狀態……嗯，真的忙到覺得自己真的有病，有時候也會想說到底為什麼要在這個時候挑戰這件事情，但最後還是會覺得，既然這些都是自己曾經花很多時間理解的東西，那就試著用自己的方式整理下來吧。希望可以把那些以前覺得很難的觀念，慢慢變成比較容易理解的內容。

讓我真正花時間的契機

曾經有一位新人同事 A 跑來問我：

「我現在開始學 Angular，但看了 source code 還是不知道它到底是怎麼做出來的。安東尼，你知道 Angular 是怎麼做到響應式的嗎？」

當時的我，其實還在讀《Vue.js 設計與實現》，心裡 OS：如果我知道，我可能就不會坐在這裡。但也因為這個問題，我才突然意識到，自己雖然用了 Angular 一段時間，卻好像從來沒有真正去理解過它背後是怎麼運作的。

這個現在回頭看有點好笑的開場，反而在我心裡留下了一個念頭：也許有一天，我可以試著把 Angular 背後的一些原理，用更簡化、更容易理解的方式講出來。這樣一來，這幾年和 Angular 的相遇，對我來說好像也會變得更有意義。

這次的系列賽

這次的系列賽，我想用一個和以往不太一樣的方式，來聊聊 Angular Signal 到底帶來了哪些改變。

一路看著 Angular 每個版本持續演進，也會發現 Signal 相關的 API，慢慢從實驗性功能走向穩定。從一開始只有 signal()，到後來出現 linkedSignal()、Resource API，甚至延伸到 Signal Forms，Angular 正在一步一步補齊以 Signal 為核心的開發方式。

在 AI 世代下，坦白說，我也曾經覺得壓力真的很大。當 AI 好像什麼都會的時候，我也開始想：那我到底還能怎麼放大自己的價值？但想了一段時間之後，我最後找到的答案，還是回到「理解」這件事情上。除了知道一個 API 怎麼使用之外，我更希望自己能理解它為什麼會出現、想解決什麼問題，以及當系統越來越複雜的時候，該怎麼做出適合的設計與選擇。

我一直覺得，在 AI 越來越方便的現在，如果太習慣直接相信它給的答案，反而有可能慢慢失去自己思考與判斷的能力。不是 AI 不好，而是我還是希望在使用 AI 的同時，保留自己的理解、觀點與選擇。所以這次的文章，我也不打算只是整理 Angular Signal API 的使用方式，而是希望多花一點時間去理解它背後的想法，再用自己的方式把這些內容整理下來，就當作是在跟大家聊聊天。

至於這次能不能順利完賽，我其實也不敢保證，因為這次沒有事先準備文章庫存。但我想這也沒關係，只要每天願意多理解一點、多整理一點，對我來說就已經很有意義了。

Let’s begin our Angular Signals journey!